Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Fri Dec 11 16:06:26 1992.msg

Internet Message Format | 1994-01-24 | 4KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA12408; Fri, 11 Dec 92 16:06:26 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA16140; Fri, 11 Dec 1992 16:19:54 +0100
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA14739 (5.65b/3.2/CWI-Amsterdam); Fri, 11 Dec 1992 16:19:47 +0100
Received: by voorn.cwi.nl with SMTP
    id AA00320 (5.65b/3.2/CWI-Amsterdam); Fri, 11 Dec 1992 16:19:45 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Gopher+ Considered Harmful
In-Reply-To: Your message of "Fri, 11 Dec 1992 15:18:01 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 11 Dec 1992 16:19:45 +0100
Sender: [e-mail]

Tim writes:

>It is not the space to buffer the stuff in the average case which is a problem
>
>There are extreme cases: Long documents which spew out of format converters
>piped into other format converters.  These things wouyld blow the memory of a
>server which we never like to do.
>
>There is the cumulative effect of response times. Curerntly, almost all the W3
>code is pipelines, so the reponse (click mouse to first character on screen)
>is a function of the round trip delays and any real retrieval time. The moment
>you put a buffer in to count bytes, you have to wait for the first until the
>last is available. In the (frequent) case of many stages being involved in a
>pipeline the response time does not in fact increase much, you just get a lot
>of CPU from processors on the pipe line.  Once you buffer it up, you are using
>CPU from one processor at a time.   You can't start displaying it until you've
>parsed it and you can't parse it until you've read it and you can't read it
>until the server has counted it and he can't even start to count it until all
>the real work has been finished.
>
>You will notice the difference immediately.

Yes, I see.  This means there is a problem whether you put a byte
count in the header or in an "envelope" sent before the header, so
Dan's solution is just as wrong as mine. :-(

>Piping things until EOF is so much faster.  Can TCP really not tell the
>difference between a remote connection close, and a broken connection? :-((
>(APIs apart)

I tried to find out a definitive answer but it is hard to figure out.
At the kernel level there is definitely a difference between a
shutdown by the remote side and a network failure, but at least on
UNIX both situations are passed to the client as an EOF.

One solution would be to add a standard string after the document,
e.g. CR LF "*%*%*%END-OF-DOCUMENT%*%*%*" CR LF, so that the client can
assume it has received the whole file if it sees this at the end of
the file.  The client cannot assume that the data *ends* when it sees
this (it is not another form of dot-on-a-line-by-itself), since it may
occur within the data as well, but it will know that it didn't get the
whole data if it doesn't end with this.

A better version would be to if the server could calculate a simple
checksum or "signature" (e.g. MD5) of the data and append this to the
end of the data.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I'm sorry but I'm not allowed to argue unless you pay."